Executing applications from a semiconductor nonvolatile memory

ABSTRACT

A processor-based device (e.g., a wireless device) may include a processor and a semiconductor nonvolatile memory to directly execute an application (e.g., an execute-in-place application) using an associated database. Within a flash memory, in one embodiment, an executable program may be separately stored in a non-fragmented manner from a resident database that includes program management information for use in an execution that does not involve a random access memory, saving time and resources.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of pending U.S. patent application Ser. No. 13/041,541 filed Mar. 7, 2011, which is a continuation of U.S. patent application Ser. No. 10/215,549, filed on Aug. 8, 2002 and issued as U.S. Pat. No. 7,904,897 on Mar. 8, 2011. The aforementioned applications, and issued patent, are incorporated herein by reference, in their entirety, for any purpose.

BACKGROUND

This invention relates generally to semiconductor nonvolatile memories operable with target devices, and more particularly to executing from a semiconductor nonvolatile memory such applications that may have a resident database on a processor-based device.

Many processor-based devices, such as consumer devices for use in portable environments or otherwise, may include a semiconductor nonvolatile memory for erasably and programmably storing information that do not need to be periodically refreshed. One type of commonly available and used semiconductor nonvolatile memory is a flash memory. With the rise of content driven networks, many user applications require a mix of code and data to operate the consumer devices. For instance, a variety of wireless devices including cellular phones include a flash memory to store different data files and resident applications. Likewise, a portable device, e.g., a personal digital assistant (PDA), incorporates a flash memory for storing, among other things, certain operating system files and configurable data. In some situations, a flash memory may allow data found in application programs to be stored and manipulated by a resident file management system. In addition, memory managers included in a target device handle the housekeeping functions of code and data management. Typically, file systems and memory managers in conjunction with the device hardware enable users of such devices to subscribe and receive a variety of ancillary services apart from contributing in basic device operation.

However, application programs and resident data associated with such services and/or basic device operation may need to be managed, e.g., periodically updated within a target device. For application management, a variety of application programs including execute-in-place (XIP) applications may need to be stored and executed in the target device. Typically, to execute an application, an executable form of the application is stored along with a database on a flash memory. Thereafter, the executable form of the application is read for loading, copied to a random access memory (RAM), and reassembled into an executable file that can be executed on the target device. This loading and reassembling of the application in the RAM inevitably introduces operational efficiencies while exhausting precious RAM resources. Moreover, before the application may be executed, a startup time may be consumed to begin a RAM operation, adversely delaying any desired updates at the target device particularly in time critical circumstances.

Thus, there is a continuing need for better ways to manage applications in a target device, especially executing applications from a semiconductor nonvolatile memory that may have a resident database.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic depiction of a processor-based device consistent with one embodiment of the present invention;

FIG. 2 shows a memory map of a partitioned flash memory that may be located within the processor-based device of FIG. 1 in which an executable-in-place program is stored separately from a database, enabling direct execution of the execute-in-place program corresponding to an application in accordance with one embodiment of the present invention;

FIG. 3 is a flow chart for software to execute the application from a semiconductor nonvolatile memory included in the processor-based device shown in FIG. 1 according to one embodiment of the present invention;

FIG. 4A shows a wireless communication device that uses the software of FIG. 3 consistent with one embodiment of the present invention; and

FIG. 4B shows a wireless-enabled computing device that uses the software of FIG. 3 according to another embodiment of the present invention.

DETAILED DESCRIPTION

A processor-based device 20, as shown in FIG. 1, includes a controller 25 such as a processor that may control an interface 30, permitting a read and a write access according to one embodiment of the present invention. The processor-based device 20 further includes a random access memory (RAM) 35 and a read only memory (ROM) 40 both coupled to the controller 25 via an internal bus 45. While the RAM 35 may be provided to store updateable data or programs, the ROM 40 may be used to store programs that do not require any update during execution. A semiconductor nonvolatile memory 50 is coupled to both the RAM 35 and the ROM 40 by the internal bus 45 in one embodiment in the present invention. Using a database engine 55, the controller 25 may provide direct access to the semiconductor nonvolatile memory 50.

At some point, a database 60 may be loaded in the semiconductor nonvolatile memory 50 in addition to an application 65 according to one embodiment of the present invention. Specifically, the application 65 may be transformed into an executable program which may be stored separately in a non-fragmented manner from the database 60. The database 60 may include program management information for managing the application 65 in one embodiment of the present invention. For execution of the application 65, the database engine 55 may be loaded in the ROM 40 in one case. Furthermore, a reference link 70 may logically link the application 65 with the database 60 within the semiconductor nonvolatile memory 50.

Consistent with one embodiment of the present invention, the database engine 55 may include code manager software 75 for managing the execution of the application 65 from the semiconductor nonvolatile memory 50. Upon initialization, at some point, the code manager software 75 may execute the application 65 based on the program management information stored within the database 60. In one embodiment, the program management information may comprise registry entries 80 a-80 b. Registry entries 80 a-80 b may incorporate conventional meta-information that is typically used to manage the application 65. Examples of the registry entries 80 a-80 b may include registry information, such as an install date, install version, and installer information.

Specifically, the application 65 may be contiguously stored as an executable program in a linear fashion within the semiconductor nonvolatile memory 50 so that the executable program may be directly executed, demand paged, and/or memory mapped in some embodiments of the present invention. This executable program represents the application 65 in an execute-in-place (XIP) application form accordingly. Corresponding to the execute-in-place (XIP) application, a binary representation of the application 65 for the executable program may be used. For managing the application 65, the database 60 may be leveraged by creating an application management database schema, encompassing the registry entries 80 a-80 b. That is, in one embodiment, the application management schema associates all the registry entries 80 a-80 b in a structured manner that is useful in database operations. Within the semiconductor nonvolatile memory 50, a database entry for the binary representation of the application 65 being managed may be provided. In this manner, the application 65 may be linked to the registry entries 80 a through 80 b of the database 60 via the reference link 70.

The semiconductor nonvolatile memory 50 may be a flash memory in some embodiments of the present invention. A flash memory is a type of semiconductor nonvolatile memory, which allows a user to electrically program and erase information therefrom. Using this unique feature of the flash memory, the processor-based device 20 may be desirably managed and updated. That is, in one embodiment, the application 65 and/or the database 60 may be upgraded or reconfigured in response to an indication signaling an update of the flash memory. When such an indication is provided, an appropriate update of the flash memory may be undertaken in the processor-based device 20. In response to the indication, the application 65, i.e., the executable program may be executed from the flash memory using the execute-in-place (XIP) application and the schema according to one embodiment of the present invention.

Although one embodiment is described in conjunction with a flash memory storing the database 60 and the application 65 for execution via the code manager software 75 without using the RAM 35, other suitable nonvolatile solid-state memories may be deployed in some embodiments without deviating from the spirit and scope of the present invention. To mention a few examples, any type of erasable programmable read-only memory (EPROM) that can be conventionally and electrically arranged or programmed may be used in some embodiments of the present invention. Consistent with one embodiment of the present invention, the database engine 55 may be any known database management program capable of maintaining a database, storing one or more database entries. Likewise, the code manager software 75 may correspond to a semiconductor nonvolatile memory file management program capable of interfacing with a file system and/or an operating system.

In operation, the database engine 55 may be loaded into the ROM 40 within the processor-based device 20. For execution, the database engine 55 may be downloaded from ROM 40 into the RAM 35, according to one embodiment of the present invention. Alternatively, the database engine 55 including the code manager software 75 may be preloaded into the semiconductor nonvolatile memory 50. For example, in some embodiments of the present invention, flashware may control the operation of a flash memory, i.e., the semiconductor nonvolatile memory 50.

A memory map of a partitioned flash memory 50 b is shown in FIG. 2 in which the application 65 executes an executable program 100 without using a RAM 35 b in accordance with one embodiment of the present invention. The need to copy the application 65, i.e., the corresponding executable program 100 in the RAM 35 b, and the subsequent reassembly of the executable program 100 is obviated. Rather than storing the executable program 100 in a segmented manner within the database 60, the executable program 100 may be stored in the flash memory 50 b in a non-segmented manner, in one embodiment. Such a non-segmented storage, in one embodiment, entails a continuous, linear storage for an execute-in-place (XIP) application program corresponding to the executable program 100, allowing the application 65 to execute directly from the flash memory 50 b. This at least saves the startup time for the RAM 35 b and avoids use of the RAM 35 b while executing the application 65 in some cases. In operation, the execute-in-place (XIP) application program corresponding to the executable program 100 may be executed from the flash memory using an application management database schema 90 including the meta-information entries 85 a-85 b according to one embodiment of the present invention.

To store the executable program 100 in a continuous, linear fashion within the flash memory 50 b, the code manager software 75 may be utilized in one embodiment. The reference link 70 may associate the code manager software 75 with the database 60, i.e., the meta-information entries 85 a-85 b, linking the executable program 100 for the application 65. In this way, loading and reassembling of the application 65 into the RAM 35 b of the flash memory 50 b may be avoided because the XIP program objects 95 a-95 d are stored in a non-segmented manner, significantly reducing the overhead associated with the execution of the application 65. Using the code manager software 75, the executable program 100 may be executed directly from the flash memory 50 b, in some embodiments of the present invention.

Advantageously, a substantially larger amount of meta-information may be provided in the database 60 than otherwise possible by leveraging the application management database schema 90 for meta-information including “registry” type meta-information with the code manager software 75 that stores the application 65 in a contiguous, linear fashion. More specifically, because the meta-information may be independently stored from the code manager software 75 in meta-information entries 85 a-85 b, a significantly large amount of data may be maintained for the application 65 within the flash memory 50 b. In this way, appropriate application management may be provided for the application 65 by leveraging both the meta-information entries 85 a-85 b of the application management database schema 90 and the reference link 70, linking the executable program 100 to the database 60.

Referring to FIG. 3, the code manager software 75 may receive for storage the executable program 100 at the flash memory 50 b, at block 120. A check at diamond 122 may ascertain whether or not an associated database (e.g., the database 60 shown in FIG. 1) is resident in the processor-based device 20 (FIG. 1). For instance, if the database 60 is detected to be present within the flash memory 50 b, the executable program 100 may be stored separately from the database 60 in a non-segmented manner for an associated execute-in-place (XIP) application, such as the application 65 shown in FIG. 1, at block 124. At block 122, if a database is not detected then, the executable program 100 may be stored at an appropriate location within the flash memory 50 b, at block 123. If no resident database is detected at the processor-based device 20, the code manager software 75 may terminate in some embodiments of the present invention. Alternatively, a relevant database may be requested.

A check at diamond 126 may determine whether or not a link, such as the reference link 70 is provided between the database 60 and the executable program 100. If so, by using the reference link 70, the database 60 may be logically linked to the application 65 at block 128. At the block 126, however, if such a link is determined to be missing, then, the meta-information entries 85 a-85 b may not be associated with the XIP program objects 95 a-95 d of the executable program 100. That is, if at the diamond 126, it may be determined that the reference link 70 is not desirable because either there is no resident database available at the flash memory 50 b or a preexisting reference link is detected then, linking of the database 60 and the application 65 may be deemed unnecessary. More particularly, in one embodiment, a pointer may be provided for the reference link 70 from the last meta-information entry 85 b to the first XTP program object 95 c, storing an initial portion of the executable program 100.

A check at diamond 130 may detect an update indication for the flash memory 50 b at a target device, e.g., the processor-based device 20 (FIG. 1). In response to the update indication, at block 132, in one embodiment without using the RAM 35 b, the executable program 100 may directly execute from the flash memory 50 b. Conversely, if at the diamond 130 no update indication is detected then, the execution of the executable program 100 may be skipped at the processor-based device 20 in some embodiments of the present invention.

To store media content received or sent over a network, the semiconductor nonvolatile memory 50, such as a flash memory may be deployed in some embodiments of the present invention. As an example, a cellular phone may use the flash memory for parameters, data storage and code file management in some situations. Alternatively, a flash memory within a PDA may be used at least for file storage in one embodiment.

A wireless communication device 150 shown in FIG. 4A may include a wireless interface 155, a user interface 160, and an antenna 170 in addition to the components of the processor-based device 20 (FIG. 1) according to one embodiment of the present invention. Examples of the wireless communication device 150 include mobile devices and/or cellular handsets that may be targeted for providing various subscriber services by database vendors or service providers. To manipulate such services or simply activate or reconfigure a device, update indications may be provided over an air interface to the wireless communication device 150 in one embodiment. In any event, for executing the application 65 from the semiconductor nonvolatile memory 50, the wireless interface 155 may be operably coupled to the antenna 170 via the internal bus 45 to exchange network traffic.

Likewise, a wireless-enabled computing device 175 shown in FIG. 4B may include a communication interface 180 operably coupled to a communication port 182 that may communicate information to and from the flash memory 50 b in accordance with one embodiment of the present invention. While, a keypad 185 may be coupled to the user interface 160 to input information, a display 190 may output any information either entered into or received from the user interface 160. The wireless interface 155 may be integrated with the communication interface 180 which may receive or send any wireless or wireline data via the communication port 182. For a wireless communication, the antenna 170 may operate according to any suitable one or more network communication protocols capable of wirelessly transmitting and/or receiving voice, video, or data. Likewise, the communication port 182 may be adapted by the communication interface 180 to receive and/or transmit any wireline communications over a network.

Furthermore, the flash memory 50 b may include a flash database (DB) engine 55 a, incorporating the code manager software 75. An XIP application 65 a may be separately stored from a meta-information database 60 a within the flash memory 50 b in some embodiments of the present invention. By leveraging both the meta-information database 60 a and the code manager software 75, the XIP application 65 a may be executed from the flash memory 50 b, e.g., in response to an update indication received either over the antenna 170 or at the communication port 182. Database vendors or service providers may be able to target the wireless-enabled computing device 175 for providing updates for the VP application 65 a and other features using the flash memory 50 b and the code manager software 75 in some embodiments of the present invention.

As an example, in one embodiment mobile devices and/or cellular handsets may benefit from such an application management technique based on the code manager software 75. In mobile and handset environments increase in complexity may drive the demand for a full-featured and robust flash memory management system to manage and execute applications including the application 65. In one embodiment, the code manager software 75 may be incorporated in flash management software, providing an ability to manage code, data, and files in the flash memory 50 b. The flash management software may be used in real-time embedded applications in some embodiments. Additionally or alternatively, the flash management software in an open architecture may provide support for applets, file transfers, and voice recognition. Using an application program interface (API) that supports storage of parameter data, data streams for multimedia, Java applets and native code for direct execution, and packetized data downloads may be provided in some embodiments of the present invention.

Advantageously, the flash management software may allow a user to store binary code contiguously in the flash memory 50 b, which may be run directly without copying the code to the RAM 35 b for execution. This code may range from native software compiled strictly for a processor in a system, to downloaded code, which is read and interpreted by a middleware application (such as an applet). The flash management software may allow managing of this code, i.e., write, delete, and modify operations may be applied to a code object in the flash memory 50 b via the flash management software application program interface (API) in one embodiment. The flash management software may enable XIP code execution by fetching a code object's location address in the flash memory 50 b.

In another embodiment, a virtual small block file manager (VFM) being flash software reference code may provide for disk-like sector and file access to the flash memory 50 b, as an example. In addition to data storage capability, VFM file manager may accommodate handling code in the same component, i.e., the flash memory 50 b. The VFM file manager, and the underlying virtual small block (VSB) flash media manager as a flash reference code may be used by original equipment manufacturers (OEMs) who need file manager capability, or who need to add flash media management to an existing sector based embedded file manager. The full VFM (VFM and VSB) may be used as the system file manager to the flash memory 50 b, or may be adapted to operate under an existing file system/operating system through an API. Moreover, the VFM file manager may handle general file manager functions including but not limited to: file open, file close, file write, file edit, file delete, file seek, tell, reclaim, power-off recovery and cleanup functions

In one case, flash storage manager software may combine all semiconductor nonvolatile memory functions into a single chip. A combination of executable code, registry back-up, and file storage may be obtained in a single flash memory, such as in the flash memory 50 b. By integrating both executable code and file storage functions into a single flash chip, a system using an operating system (OS) may store both code and data. Working in conjunction with a ROM file system in the OS, a simultaneous access may be provided to separate code and file partitions in the same flash chip. The code may be directly executed, demand paged, or memory mapped in some embodiments of the present invention.

While the present invention has been described with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention. 

What is claimed is:
 1. A method comprising: storing within a non-volatile memory: an executable program in a non-fragmented manner, registry entries, and code management software, wherein the executable program, the registry entries, and the code management software are stored separately within the non-volatile memory; and executing the executable program directly from the non-volatile memory based on the code management software without moving the registry entries to a volatile memory.
 2. The method of claim 1, further comprising contiguously storing the executable program in a linear fashion.
 3. The method of claim 2, further comprising: forming a schema of the code management software; and forming an execute-in-place application of the executable program.
 4. The method of claim 3, further comprising: providing a flash memory for the non-volatile memory, the flash memory located in a portable device; detecting at the portable device an indication to update the flash memory; and responsive to the indication to update the flash memory, using the execute-in-place application and schema to execute the executable program from the flash memory.
 5. The method of claim 1, further comprising: associating, via a reference link, a meta-information database resident in the non-volatile memory with the executable program; receiving an update indication for the non-volatile memory; and responsive to the update indication, using the meta-information database and the reference link to execute the executable program from the non-volatile memory.
 6. The method of claim 5, further comprising: storing the registry entries in the meta-information database; and forming a schema of the registry entries in the meta-information database.
 7. The method of claim 6, further comprising: providing the executable program an execute-in-place application in one or more objects, each of the one or more objects configured to hold a portion of the executable program; and running the execute-in-place application at the non-volatile memory responsive to using a database engine, the one or more objects, and the schema.
 8. The method of claim 7, further comprising storing in the database engine the one or more objects in a binary format at a different location than the registry-type information of the meta-information database at the non-volatile memory.
 9. The method of claim 1, further comprising linking the executable program stored in the non-volatile memory to an associated database.
 10. The method of claim 7, further comprising directly executing the executable program from the non-volatile memory without copying the one or more objects for reassembly in a random access memory.
 11. A device comprising: a processing device; and a non-volatile memory communicatively coupled to the processing device, the processing device configured to separately store in the non-volatile memory an executable program in a non-fragmented manner, registry entries, and program management information, wherein the processing device executes the executable program from the non-volatile memory based on the program management information and without moving the registry entries to a volatile memory.
 12. The device of claim 11, further comprising a database configured to store the program management information, wherein the database is linked with the executable program within the non-volatile memory via a reference link.
 13. The device of claim 11, wherein the non-volatile memory is configured to store the executable program in a contiguous and linear fashion.
 14. The device of claim 13, wherein the program management information includes a schema and the executable program corresponds to an execute-in-place application.
 15. The device of claim 14, wherein the non-volatile memory comprises a flash memory operably coupled to a portable device.
 16. The device of claim 15, wherein the non-volatile memory detects an update indication at the portable device and, responsive to the update indication, executes the executable program via the execute-in-place application and the schema.
 17. The device of claim 13, wherein the execute-in-place application is stored in one or more objects for the executable program, each of the one or more objects configured to hold a portion of the executable program.
 18. The device of claim 13, further comprising a database engine to run the execute-in-place application at the non-volatile memory using the schema and the one or more objects.
 19. The device of claim 18, wherein the database engine is configured to store the one or more objects in a binary format at a different location than the program management information of the database.
 20. The device of claim 19, wherein the execute-in-place application in configured to directly execute the executable program from the non-volatile memory without copying the one or more objects for reassembly in a random access memory. 